Amazon OpenSearch Service コンソールで「No server available to handle the request」エラーが表示される場合の対処方法
困っていた内容
Amazon OpenSearch Service (旧: Amazon Elasticsearch Service) コンソールにて以下のエラーが表示されます。
/_cluster/health: { "message": "No server available to handle the request", }
また、OpenSearch Dashboards (旧: Kibana) へアクセスすると以下のエラーが返却されます。
"message": "No server available to handle the request",
Amazon OpenSearch Service や OpenSearch Dashboards の操作ができなくなっているので対応方法を教えてください。
どう対応すればいいの?
原因
Amazon OpenSearch Service コンソールからクラスターのヘルスタブを確認し、クラスターのステータスメトリクスが赤で、JVM メモリプレッシャー(JVMMemoryPressure)メトリクスが 90 %前後など高い値を示している場合、継続的な高負荷のために該当のエラーが発生している可能性が高いです。
対応方法
この場合の対応方法としては、ヘルスステータスが赤になっているインデックスを削除することとなります。
以下のコマンドでヘルスステータスが red (赤)になっているインデックスを確認します。
curl -XGET <Amazon OpenSearch Service のドメインエンドポイント>/_cat/indices?v
そして、以下のコマンドで対象となるインデックスを削除していきます。
curl -XDELETE <Amazon OpenSearch Service のドメインエンドポイント>/<index_name>?pretty=true
また、問題のインデックスを削除することができなかった場合は、以下の対処方法についてもお試しください。
- スナップショットから復元する
- 対象のインデックスからドキュメントを削除する
- 古いインデックスを削除してディスク領域を解放する
上記の操作についても困難な状況である場合は、対象ドメインの ARN と確認したエラー内容、対応内容などの詳細を添えて AWS サポートにお問い合わせを実施してください。
構成内容の変更を検討する
Amazon OpenSearch Service のベストプラクティスを参考にする
上記に記載の対応を行なってクラスターのステータスが緑に戻って操作が可能になった場合や、 スナップショットを利用して新規ドメインを作成することでの復旧を選択した場合、従来と同様の構成にて運用を続けると同様のエラーが再度発生する可能性が高いです。
Amazon OpenSearch Service のベストプラクティスを参考に構成内容の変更をご検討ください。
- t2/t3.small インスタンスを本番環境で使用しない
- ドメインの適切なサイズ設定を行う
- 各インデックスごとに少なくとも 1 つ以上のレプリカを設定する
- ドメインを 3 AZ で展開する
- 3つの専用マスターノードを使用する
ドメインの適切なサイズ設定については、以下で解説します。
ドメインの適切なサイズ設定とは
例えば t3.medium.search で 3 ノードでの運用を行なっている場合を考えてみましょう。
t3.medium.search ではノードに割り与えられるメモリは 4 GiB なので、その半分の 2 GiB がヒープ領域として割り与えられます。 Amazon OpenSearch Service ではヒープ領域 1 GiB につき 20 シャード未満に保つことが推奨されております。
そのため、3 ノードで展開している場合は、
2 GiB x 20 シャード x 3 ノード = 120 シャード未満
が運用上の適正値となります。
自身の構成で計算を行ってみて適正値を大幅に超えるシャードが存在する場合は、インデックスを削除してシャードの数を減らす、ノードのスケールアップ、ノードを追加するといった対応を実施してください。
OpenSearch Service では Java ヒープ (最大 32 GiB のヒープサイズ) にインスタンスの RAM の半分を使用します。インスタンスは最大 64 GiB の RAM まで垂直スケーリングでき、それ以上はインスタンスを追加することで水平方向にスケーリングできます。
ノードごとに、Java ヒープの GiB あたりのシャード数が 20 個を超えないようにしてください。たとえば、m5.large.search インスタンスには 4 GiB のヒープがあるため、各ノードのシャードが 80 個を超えないようにしてください。